I'm a bit puzzled by this interface. I think it is mixing the flash concepts (board or driver defined) with the qspi concepts (cpu defined). I don't think the cpu's qspi module should have knowledge about 0x6B being a read command. This depends on the mode you have configured on the flash and varies between flash chips.

QSPI read operation means that all four IO0~3 are controller-driven for a certain number of clocks (opcode + 0 to 4 address bytes) and then they are peripheral-driven for the remaining number or clocks. This support is what I have seen in various cpus.

Depending on the flash chip, flash chip mode or the opcode the address would be also in quad mode, but I don't think that's something this interface should deal with. The flags in configure function would probably need to have the address-length, quad vs dual mode, and the number of dummy bytes, which also changes at runtime because of the different modes/commands you can send to a flash (not all commands are just fast_reads or fast_writes).

I'd propose for QSPI operation to have only these two instead of the 4 functions here:

ssize_t qspi_read(qspi_t bus, uint8_t cmd, uint32_t addr, void *data, size_t len);
ssize_t qspi_write(qspi_t bus, uint8_t cmd, uint32_t addr, const void *data, size_t len);

These functions could also serve as the single-mode operation using the 1bit mode in the flags. I didn't see full-duplex like in regular SPI blocks (read from IO1 while write to IO0) supported in the QN9080 or nRF52840. Howver, at least a function that lets you do send N bytes in single mode and then receive M bytes would be very useful, again this could be just qspi_read with the proper flags. In QN9080 I think N<=5 and in NRF52840 N<=8 is possible, and it is needed to send other commands.

I would add here number of dummy cycles after the address, more address length options (1-4 bytes) and whether the address is also transmitted in quad mode.

This means IO0 to IO7 pins? Do you have an example CPU that supports this?

STM32H7 supports Octo-SPI 🐙

I don't think this belongs here. In the NOR case this is not in the cpu's spi case, and we could use this module with chips that don't necessarily conform to these registers.

qn9080 and nrf52840 both support memory mapping a flash to a region. To do that you need to program a command (like the fast_read command) and an address format, so then you can read from MCU memory directly which will generate a QSPI transaction automatically, even with some caching, allowing very fast reads without any call overhead. This is often incompatible with running a command at the same time, so something like qspi_configure but for configuring memory reads that returns the pointer/size would be good to add here. It is probably an addition to this module, meaning that you would need to have MODULE_QSPI_MAPPING defined, but it is worth considering the idea in this design so we don't have to change it later.

SAM D5x/E5x has that too, but the memory region where this is mapped to is fixed.
I have a branch where I implemented qspi_xip_mount() - haven't pushed that yet because I couldn't get the flash chip out of XIP mode without doing a power reset.

I assumed that in this mode you can only read, not write to the flash.

Reading the datasheet it seems that you can only read, but it is not very clear. The nRF52840 has registers for configuring the READ, WRITE and ERASE opcodes, but I can't quite tell if the chip handles writes or not. QN9080 says it only handles reads and actually XIP is not recommended because it is too slow.

I think this is another example of code that shouldn't go into the qspi cpu driver: sending commands to enabled/disable the xip mode in the flash chip (looking at your code I understand you mean no-opcode mode). Some chips use 0xa5 for entering this mode and 0xff to exit, but this depends on the flash chip, not the cpu, and it varies a bit across manufacturers. For this what's needed is a way to set the dummy bytes to send (probably in the flags, or similar).

The XIP mount memory region is normally a window of certain fixed size and address; but you could have a different base flash address if the flash is larger than the window. I don't see this feature in the samd5x, but nrf52840 has the XIPOFFSET register for this purpose. I think that when configuring the memory mapping (xip_mount in your branch) the caller should pass the configuration: command (if any), whether an command is needed, the flash base address; and the driver would return the memory address corresponding to the requested base address. If windowing is supported you would set that in the xipoffset register for example, but if there are alignment requirements for this offset or having an offset is not supported the driver could return an address into the fixed region (like AHB_XIP+base_address or AHB_XIP + base_address % min_alignment while setting the offset to another register). The caller in this example would be a qspi_nor driver, which is different from a qspi_flash driver for example but the same across CPUs. I'd imagine that the qspi_nor driver can send commands to enable the XIP mode in the flash (depending on the flash) and then tell the qspi.h interface to do xip_mount with no opcode; or don't set the XIP mode in the flash if not supported and then tell the qspi.h to do xip_mount using certain opcode for reads.